Log Analyzer — oq verdict: FAIL

Test outcome (from orchestrator): FAILED
CF target: deploy-service / sap_btp_cf_mta_deploy+technical1 (app: deploy-service, deployed sha: 2287e92)
Window: 2026-05-22T12:13:27Z → 2026-05-22T12:57:52Z
Index queried: logs-* (cluster: green, index auto-selected from window+app filter)
Total WARN: 4384 | Total ERROR: 616 | Truncated: yes (5000 of 5478 total hits retrieved; cap reached — up to 478 late-window entries not analyzed)
Window-anchor cross-validated: YES — window_start (12:13:27Z) correctly placed after deploy_start (12:11:20Z), confirming anchor at DEPLOY_END.

Verdict rationale

The OQ run failed across 6 scenarios. Log analysis identifies two pre-existing regression candidates that are unrelated to the PR's code changes. PR 1842's actual diff is minimal and safe (a log message text change in Messages.java and an unused TEST constant in DataTerminationService.java); neither file is involved in service binding, hook execution, or any of the failing scenarios. The failures are caused by (1) a newly-added OQ test (multiple-bindings-scenario, merged 2026-05-14) that exercises a CF state — two bindings between the same app and service instance — which the controller's reactor chain does not handle, and (2) a newly-added OQ test (hook-target-app, merged 2026-05-13) that relies on a phases-config hook parameter that is not implemented in the controller's SupportedParameters. The remaining four failing scenarios (gacd-with-optional-resource, generic-content-deploy, shared-private-domain-scenario, nginx-rate-limit-parallel-requests) show only WARN-level or expected-error log activity with no new regression signals. PR 1842 is not the cause of the OQ failures.

Local git state at analysis time

multiapps-controller feature branch (qa-pr-1842) contains 2 commits vs master:

• 2287e9286 — DataTerminationService.java: adds an unused private final String TEST = "test" field. No behavioral impact.
• e5a2f1849 — Messages.java: renames the log constant DELETED_ORPHANED_MTA_DESCRIPTORS_COUNT text from "Deleted orphaned mta descriptors count: {0}" to "Deleted descriptors count: {0}". No behavioral impact.

Neither file is involved in service binding operations, hook processing, or any of the failing OQ scenarios.

cf-mta-examples feature branch (feature/restructure-hooks-examples): introduces hooks/blue-green-deploy-hooks/with-target-app/mtad.yaml which uses the phases-config / target-app: idle hook parameter — the same parameter the hook-target-app OQ test uses. This feature branch is consistent with the OQ test expectations and further confirms the controller is missing this parameter's implementation.

Deploy chain version pinning

All three downstream properties are out of sync with their source-of-truth versions. Per CLAUDE.md "Deploy chain version pinning", this is a hard correctness invariant. A bp.sh push while these are mismatched will cause Maven to resolve stale artifacts from the local repository and ship old code in the deployed WAR while the build reports success.

• multiapps-controller declares multiapps.version=2.48.0 but multiapps is at 2.49.0-SNAPSHOT — the deployed WAR may contain the 2.48.0 version of the MTA model/parser library, not the current workspace HEAD.
• xsa-multiapps-controller declares multiapps-controller.version=2.47.0-SNAPSHOT but multiapps-controller is at 2.45.0-SNAPSHOT — inconsistent direction (declared version is higher than truth), indicating a merge divergence.

Recommendation: Before the next deploy, run the pin-and-revert procedure from CLAUDE.md. These skews should be treated as potential confounds for any OQ result until resolved.

Categorization

Note: The 1079 "regression-related" count is intentionally conservative — it includes all entries that did not match the expected-OQ or infra patterns. After manual triage below, the actionable regression-suspect signatures narrow to 2 (the hook-target-app and multiple-bindings-scenario failures). The remaining ~1069 are known OQ noise patterns that the categorizer's allowlist did not cover (e.g., Skipping deletion of services, Error while closing command context as Flowable cleanup from expected test-induced failures, etc.).

Potentially regression-related (investigate)

C-1 — multiple-bindings-scenario: "Source emitted more than one item" in service binding check

Occurrence: 11 hits (8x WARN retries + 3x ERROR dead-letter), all on correlation ID 7f3f080e-55d8-11f1-b499-eeee0a9bf59d, instance 1.
Window: 2026-05-22T12:20:15Z – 2026-05-22T12:21:13Z (under 1 minute; 3 retry cycles of 2 retries each before dead-letter)

Sample stack excerpt:

Dead letter job detected for process "96ab4720-55d8-11f1-b499-eeee0a9bf59d"
(definition: "a1d49895-55d7-11f1-b499-eeee0a9bf59d"):
org.cloudfoundry.multiapps.common.SLException:
  Error while checking service binding operations between app: "anatz"
  and service instance "binding-service": Source emitted more than one item
  at org.cloudfoundry.multiapps.controller.process.steps.SyncFlowableStep.process(...)

Root cause: CloudControllerRestClientImpl.getServiceBindingResourceByApplicationGuidAndServiceInstanceGuid() (line 1748) calls .singleOrEmpty() on the result of getApplicationServiceBindingResources(). When the multiple-bindings scenario creates two bindings between app anatz and service instance binding-service, the CF API returns 2 resources, and Reactor's singleOrEmpty() throws IllegalStateException: Source emitted more than one item. This propagates through ResilientOperationExecutor (which retries 3 times) and then marks the process as dead-letter.

Attribution: The multiple-bindings-scenario OQ test was added on 2026-05-14 (XSOQTests commit c819d3f1b, "Handle Multiple bindings (#971)"). The controller code that fails — CloudControllerRestClientImpl — was last substantively changed in ef9859889 ("Migrate cf-java-client-sap") and b3db55201 ("Add support for app features enablement"). Neither is on the PR 1842 branch. The fix requires changing .singleOrEmpty() to .next() or handling multiple results explicitly in CheckServiceBindingOperationStep.

PR 1842 involvement: None. The PR touches Messages.java and DataTerminationService.java only.

Recommendation: The OQ test (multiple-bindings-scenario) was added before the controller-side fix was implemented. This is a test-implementation race condition: a new OQ test exercises a feature the controller does not yet support. Fix CloudControllerRestClientImpl to handle multiple bindings (return the most recent, or add a dedicated getServiceBindingsForApplication(app, service) that returns a list). JIRA: LMCROSSITXSADEPLOY-3409 (referenced in the OQ test commit).

C-2 — hook-target-app: phases-config parameter not recognized by controller

Occurrence: 3x WARN on phases-config unsupported-parameter, seen across correlation IDs 21715bfc-55d8-11f1-8f28-eeee0a9091d3, 538c0d18-55d8-11f1-8f28-eeee0a9091d3, b38fd236-55d8-11f1-8f28-eeee0a9091d3.
Window: 2026-05-22T12:17:02Z – 2026-05-22T12:21:06Z

Sample log:

WARN  MergeDescriptorsStep:
Parameter(s) "{hook-target-app-module#target-app-test=[phases-config]}"
are not supported in the specified scope, or referenced by any other entities.
These parameters are not processed and will be lost after the operation completes.
Further usage of these parameters might lead to unexpected results.

Root cause: SupportedParameters.MODULE_HOOK_PARAMETERS (line 220) contains only {name, command, memory, disk-quota, requires}. The new phases-config parameter (introduced for the hook-target-app feature to redirect hook execution to the idle or live app instance during blue-green deploy) is absent. As a result, the controller silently drops the phases-config block from the hook definition, causing the hook to execute on the default (live) app rather than the intended idle app — causing the test assertion about which app executed the hook to fail.

Attribution: The hook-target-app OQ test was added on 2026-05-13 (XSOQTests commit 7768dfb5e, "Add OQ test for hook target-app on blue-green deployment (#956)", JIRA LMCROSSITXSADEPLOY-3038). The cf-mta-examples feature branch feature/restructure-hooks-examples (commits 7c1fe01, 752ee2a, 59f8282) also uses this parameter in hooks/blue-green-deploy-hooks/with-target-app/mtad.yaml, confirming this is an expected new feature. The controller-side implementation — adding phases-config to MODULE_HOOK_PARAMETERS and handling it in hook execution — has not been merged.

PR 1842 involvement: None.

Recommendation: Implement phases-config support in SupportedParameters.MODULE_HOOK_PARAMETERS and add corresponding execution logic. The OQ test documents the expected behavior: a hook with phases-config: [{phase: <p>, target-app: idle}] must execute the task on the idle app instance, not the live one, during BG deploy. Until the controller implements this, the hook-target-app scenario will continue failing.

C-3 — Version skew (deploy-chain integrity)

See "Deploy chain version pinning" table above. All three downstream properties are skewed. This is escalated to Bucket C regardless of whether any log line directly references it. Risk: the deployed WAR for this OQ run may be running multiapps library version 2.48.0 code paths rather than the current 2.49.0-SNAPSHOT. If the phases-config or multiple-bindings fixes were applied in multiapps, they would not be active in the deployed WAR until the pin is corrected.

Failed scenarios provided by orchestrator

Generated by log-analyzer. Mode: oq. Generated 2026-05-22T13:00:00Z (analysis time). Consumed by pr-result-publisher.